-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stardew Valley: Improve generation performance by around 11% by moving calculating from rule evaluation to collect #4231
base: main
Are you sure you want to change the base?
Conversation
… recounting everytime rules are evaluated # Conflicts: # worlds/stardew_valley/__init__.py # worlds/stardew_valley/stardew_rule/state.py # worlds/stardew_valley/test/rules/TestShipping.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems alright as-is, with one comment about potential future worries
For the record, I also tried keeping the calculation of the total item received in the rule itself, but with caching and staling when an item is collected. It seems to improve performances as the multi world gets larger, but really does not compare with the current implementation where the calculation is made directly when collecting. |
I updated the numbers with python 3.12 and recent merges. The improvements are much higher than previously observed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes LGTM. The tests would catch most errors. Mostly just looked at the code and thought about it. Comments were addressed
@Exempt-Medic I got two peer reviews here, any chance you can do the core review? |
…g calculating from rule evaluation to collect (ArchipelagoMW#4231)
What is this fixing or adding?
This improves the generation speed of all stardew worlds, by around 11%, but more noticeably for allsanity worlds by around 19%. It moves the calculation of the total percentage of received items from the evaluation of the rule to the
collect
/remove
methods. The total is counted once every time the collection state change, instead of every time aHasProgressionPercent
is evaluated. This was discovered while discussing of #4230 with @Exempt-Medic, thanks for the inspiration.Now the
HasProgressionPercent
rule can simply extendReceived
, and checks for an event that represent directly the percentage of progression item received. No longer need to calculate the total amount of received item in the collection state.I had to fix the shipsanity tests, because they were removing the bin two times in every subtest, which would in the long run unbalance the progression item count, and eventually make some of the tests fail.
This also fixes the same Golden Walnuts bug fixed in #4230, since we no longer need to count the total amount of item in the collection state.
How was this tested?
Unit tests, plus performance tests.
If this makes graphical changes, please attach screenshots.
N/A